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1. Introduction 

1.1 Overview 

InsWeb intends to include Employee Group Benefits with its other insurance offerings. Because of its complexity, 
development of the Employee Group Benefits Rating Engine (EGBRE) design is regarded to be the most time 
consuming portion of the software development project, so work on it precedes other portions of the project. 

No formal requirements specification currently exists for the planned Employee Group Benefits application, so this 
document begins with a summary of the requirements specifications as they are currently known. Requirements and 
design regarding other portions are included only to the extent necessary to justify design of the rating engine. 

1.2 Purpose 

Beyond its use in designing and implementing the EGBRE, the purpose of this document is to solicit feedback from 
others to ensure that it is consistent with InsWeb and insurance industry conventions. 

1.3 Context 

Initial focus is on the group medical portion of Employee Group Benefits, but as details unfold regarding group 
dental, long and short-term disability, long-term care and vision products, and group life/accident/disability this 
design framework will be modified to include these other portions. 

It is important that this work and its results be consistent with other work existing or in progress at InsWeb. Of 
concern are: 

• Front end look and feel 

• Web page delivery architecture 

• Object model 

• Existing software 

• Database entities 

Where rating factor tables and algorithms are similar to those in existing InsWeb systems, feasibility of reusing 
existing software has been reviewed. 

To the extent that other insurance applications are compatible with Employee Group Benefits insurance types, 
general object relationships and database structures are designed so that they can be used in other InsWeb 
applications. 

This document does not include specifications of InsWeb project management, object architecture, data validation 
and error reporting, details of programs which call the rating engine, or billing for rating services. They are 
described elsewhere. 
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2. Requirements Summary 
2.1 Fundamental Concepts 

This section is intended to provide an overview of the context in which a rating takes place. This discussion is 
intended to bridge the gap between insurance industry terminology and application development terminology. Note 
that these concepts are discussed in abstract terms emphasizing data form rather than data content. The result of this 
discussion will be to define a candidate set of processing and data structures. Once these structures are defined, it 
will be necessary to review the requirements to demonstrate that all can be met in a manner that promotes high 
performance and straightforward application development. 

2.1.1 Factors 

The term factor is used in the insurance industry in a variety of ways. This term is discussed first to reduce potential 
confusion. 

2.1 .1 .1 Consumer (or employee) Factor 

An attribute of a consumer (e.g. location) or employee (e.g. age). Each consumer or employee factor has a value 
(location = San Mateo, or location = 94402, or location = Northern California, age = 39, etc.) which will be called 
consumer factor value or employee factor value. 

2.1.1.2 Rating Factor 

Consumer and employee factors and their values are used to determine rating factors, usually with a table lookup. 
Where a table calls for use of a particular consumer factor, the consumer factor value is used as an index to the 
table. The rating factor value found in the table is returned to be used in the calculation. 

2.1.1.3 Product Factor 

The various coverages of a policy are grouped into one or more segments (groups of coverages) for calculating and 
reporting purposes. Each segment is divided into one or more product factors, each of which frequently correspond 
to a single consumer or employee factor. 

In this simple case, the single consumer or employee factor value is used for a table lookup which returns a single 
rating factor value. In more complex cases the product factor corresponds to multiple consumer and employee 
factors, along with coverage options which are used for a multiple parameter table lookup to return a single rating 
factor value. 

In the most complex situations a single product factor can correspond to several sets of consumer and employee 
factors and coverage options, each of which corresponds to a table lookup. The several rating factors returned can 
be multiplied together, one can be the exponent of the other, or one can be used as one of the lookup values for the 
subsequent table lookup. 

After all product factors are determined, they are muhiplied together and then by a product factor base value to 
determine the segment value. Usually one of the product factors will have units of dollars and the others will be 
unitless. The final segment value will always be rounded to dollars and whole cents. 
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2.1.2 Product 

The insurance product is the primary product of an insurance company and one of two central data objects of 
concern to the rating engine. A product consists of: 

2.1.2.1 Identifying attributes 

To uniquely identify an insurance product, it will be necessary to know some or all of the following attributes. 

• Product Name 

• Carrier 

• Major geographic area 

• Product type 

• Group size, range 

• Network 

• Unique Product ID. For various companies and products, different combinations of other identifying attributes 
may be used to uniquely identify a product. The product ID will be used internally for unique identification for 
the sake of consistency. No application consumers or carriers need to be aware of this attribute. 

2.1.2.2 Coverage and Options 

Coverages are attributes of products which define that which is actually being covered, and therefore its value. The 
consumer may exercise control to fine nine the product to best meet the consumer's requirements by selecting 
values for coverages, which are called options. 

• Options are the set of allowed values for a given coverage. An option is the selected value for a coverage. 

• Not all combinations of selected options will be allowed for a given product. For simplicity, combinations are 
limited by the carrier to three basic policies allowing only a restricted set of options to the consumer. Coverage 
for which consumers will be allowed to choose among multiple options beyond the basic three policies are: 

• Deductible 

• Coinsurance 

• Stop-loss 

• Various copayments 

• Group size 

• State or major geographic area 

• Network 

• A list of all currently known coverages is included in the Product Data Entry Data Interface section below. 

2.1.2.3 Policy 

Once an option is chosen for each product coverage, the combination is known as a policy. This is the specific 
product being considered for purchase by a consumer and for which a rating is requested. 
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2.1.2.4 Segment 

Not all parts of a policy's coverage are affected by consumer and employee factors in the same way. For example, 
some parts may be affected by age, sex, and geographic area factors, while others may depend only on headcount. 
Therefore, the product may be divided into parts, called segments, with each segment having factors applied to it in 
a way different than factors are applied to other segments. Each segment has a base value (which comprises the 
calculation starting point). 

Each segment is composed of one or more product factors. Once calculated, the product factors are multiplied 
together, then multiplied by the segment base value to yield the segment value. Segment values are added together 
to provide the employee or consumer rating. 

2.1.3 Consumer 

The current or prospective purchaser of insurance. For the Employee Benefits application a consumer is a business 
with multiple employees. Each employee who elects to receive coverage represents one or more insured persons 
called members. A consumer has: 

2.1.3.1 Consumer Factors: 

Consumer factors are attributes (e.g. geographic area of employer) of the consumer used to adjust the cost of the 
insurance product (policy rating) being offered. 

• Consumer factors have names which identify them, and numeric values. 

• Once consumer and employee factors have been applied to adjust the policy rating, it is called the consumer's 
rating or simply, the rating. 

• A list of all currently known consumer factors is included in the Product Data Entry Data Interface section 
below. 

2.1.3.2 Employee 

Any employee of the consumer (employer) seeking coverage for any of the insurance types to be covered. Each 
employee is a member of the group associated with each insurance type product if they participate in that type of 
insurance. 

2.1.3.3 Employee Factors: 

Employee factors are attributes (e.g. age) of the employee used to adjust the cost of the insurance product (policy 
rating) being offered. 

• Employee factors have names which identify them, and numeric values. 

• Once employee factors have been applied to adjust the policy rating, it is called the employee's rating. 

• A list of all currently known employee factors is included in the Product Data Entry Data Interface section 
below. 

2.1.3.4 Risk Profile 

A risk profile for a consumer is the set of all consumer factors and employee factors for that consumer. The risk 
profile information is used along with the policy and rating table information to produce a rating. 
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2.1.4 Rating 

A dollar amount per month to be charged to the employer. The rating is calculated using a formula specific to the 
Product. The framework in which a specific formula is calculated is described as follows: 

• The rate is equal to a set of segment values added together. 

• Each segment value is comprised of a leading numeric factor multiplied by zero or more additional numeric 
product factors. 

• Each product factor is a numeric value determined from one or more tables, each of which is indexed by 
various consumer and employee factors and product coverage options. If there is more than one table for the 
product factor the product factor also must include information about how to relate those tables (i.e. multiply 
them together, use one as the exponent for the other, etc.) 
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2.2 Interfaces 

The Employee Group Benefits application will be comprised of seven modules (see diagram). Three of these 
interact extensively with the EGBRE directly by requesting one or more ratings to be performed or indirectly by 
providing data critical to rating calculations for later use.. Requirements and design of the other six modules will 
only be discussed to the extent to which they affect the EGBRE design. 




CARRIER 



fig 1. Employee Group Benefits Functions and Interfaces 



2.2.1 Consumer Inquiry Interface 
2.2.1.1 Functionality 

The consumer inquiry interface will collect certain information from consumers, known as the risk profile. This 
information will be made available to the EGBRE in addition to a list of the consumer's requested policies. 

• Consumers must be able to enter employer and census information (also known as a risk profile) over several 
sessions, modifying and adding to it as desired. Thus, there must be a means of persistent data storage for 
consumer information. 



Consumers must be able to return days, even weeks later (up to one year) to obtain additional ratings based on 
the same or on a modified risk profile. 
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• Consumers must be able to specify option values for a set of coverages. 

• Consumers must be able to request ratings for one or a group of policies and to repeat the process as desired. 

• For each policy, the EGBRE must be able to return total rating, rating by segment, rating by employee, and 
rating by employee by segment. 

• The EGBRE must be able to provide meaningful error information regarding missing or inconsistent data from 
the consumer's risk profile. 

• The EGBRE must be able to log detailed diagnostic data used to make a rating. It must be possible for an 
administrator to turn this feature on and off without restarting the application. 

• The EGBRE must be able to log summary information provided to the consumer inquiry interface for tracking 
purposes. This feature must be optional and depend on a request from the consumer inquiry interface. 

• Consumer location will be presented in Zip5 format. It must be possible for the EGBRE to determine which 
one, two, three, four, or five digit zip code the Consumer is within. 

2.2.1.2 Data 

The following data associated with the consumer inquiry interface will be made available to the EGBRE. 

Data types and field lengths are yet to be determined. They will depend on consumer inquiry and product data entry 
interface requirements, data standards used in the insurance industry, and other InsWeb applications and standards. 
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2.2.1.2.1 Direct 

This data will have been collected within the same session during which the rating is requested. 

Consumer identification, which must be an internally used ConsumerlD and which may be associated with an 
anonymous identifier and/or actual employer identification. The internal identifier will be sufficient for the rating 
engine to correctly associate all employer factors and census data. 

Policy identifying information for one or more policies as selected by the consumer. There may be multiple carriers 
included, multiple products for a carrier, and multiple policies for a product. 

• CarrierlD - As selected by the consumer. 

• ProductID - As selected by the consumer. 

• PolicyNo - As selected by the consumer. 

• Consumer Option (CoveragelD, OptionNo) - While many of the options are set by the policy, some are left for 
the consumer's selection. If the policy has an option it is used. If not, if the consumer has selected an option it 
is used. If neither selection has been made, then the coverages default option will be used. The consumer 
inquiry interface must determine which policies and which options best meet the consumer's criteria, then make 
that information available to the EGBRE. 

• Rating Date/Time 

Note that a single request to the EGBRE will be for a single consumer, but may be for one or more policies. 

2.2.1.2.2 Indirect 

This data may have been collected in the same session in which a rating is requested, or it may have been gathered 
during one or more previous sessions. 

• The rating engine must allow new consumer and employee factors and new units for existing factors to be 
added without modifying the rating engine programming. 

Therefore, this list of consumer and employee census factors is only suggestive of the factors necessary to perform a 
rating. 

• Consumer Factors - All consumer attributes (employer) used by the various carriers which affect the policy's 
rating will be collected as consumer factors. Not all consumer factors are necessary to calculate a rating for 
every policy. They are expected to include: 

• Geographic area - The consumer inquiry interface must specify the units (e.g. zip, county, state). They 
must be in the same units in which the policy is described (this will not generally be true) or there must be 
a means of determining whether the consumer's location is within the policy's areas (e.g. conversion or 
inclusion tables) 

• Rating Date - The date for which the rating is to be effective. It is expected that this will frequently, but 
not always be the system's current date. This date is used to calculate the trend factor, which depends on 
the number of months since the policy became effective. It must also be included with logged data for later 
review. The rating date must also be used to determine which versions of tables are in effect at the time of 
the rating. 

• Group Size - total number of employees seeking coverage of any type. 

• Industry Factor - Standard Industry Code or other designation. 
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• Pre-existing insurance factor (medical) 

• Pre-announced factor (dental) 

• Employee turnover rate (dental) 

• Participation percentage (dental) 

• Employee Census Factors - This information is to be included for each employee who is to be included in any 
type of coverage. 

• Employee age and sex 

• Spouse age and sex 

• Number of children 

• Family status (may be inferred from existence of spouse and children). Single, married, single with 
children, married with children. Note that the application requesting a rating must be able to provide this 
information according to several different tier structures. 

• Healthy lifestyle (non-smoker) Y/N 

• Hourly or Salaried (dental) 

• Employee salary (short-term disability; if coverage is percentage of salary, not if the coverage is a fixed 
cap) 

• Medical Group 

• Dental Group 

• Life Group 

• Short-term disability Group 

• Long-term disability Group 

• Long-term care Group 

• Vision Group 
2.2.1.2.3 Output 

The EGBRE will provide the following data: 

• Total rating 

• Rating by employee 

• Rating by segment 

• Rating by employee by segment 
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2.2.2 Product Data Entry 

2.2.2.1 Functionality 

Information necessary to characterize each policy for rating purposes must be made available to the EGBRE. This 
must be in a persistent form, continuously available to the EGBRE. 

• EGBRE must be able to identify the different segments of a policy and be able to perform separate ratings on 
each segment (as requested). 

• EGBRE must be able to identify which product factors belong to a segment and to multiply them together to 
calculate the segments value. 

• EGBRE must be able determine the value of each product factor by using product option values in combination 
with consumer and employee factor values to perform rating table lookups. 

• EGBRE must be able to evaluate product factors which depend on up to five total product option values, 
consumer factor values, and employee factor values. 

• EGBRE must be able to accept controlling parameters telling it how to arithmetically combine various product 
factors. It must be possible to add, multiply, and exponentiate product factors. It must also be possible to use 
one retrieved product factor as the basis for retrieving another product factor. 

• Rating tables used must include an effective date range indicating when they are to be used by EGBRE. As a 
table "times out", EGBRE must use the newer version of the table without explicit intervention. 

• It must be possible to specify a minimum value and a maximum value for a given product factor (known as 
bracketing, which is done for the total census factor for legislatively mandated products). 

• Product tables will use the leading one, two, three, four, or five digits of the Zip code. It must be possible for 
the EGBRE to determine which table entry corresponds to which five digit consumer zip. Please note that this 
issue is not yet completely resolved. Further input from the consumer inquiry interface design effort will be 
necessary. 

2.2.2.2 Data 

Data regarding products comes from both the Product Data Entry module and the Batch Rating Data Upload 
module. Because the rating engine retrieves this data from persistent storage it does not interact directly with either 
module. The data to be provided is detailed here and not repeated in the Batch Rating Data Upload section. 

Data types and field lengths are yet to be determined. They will depend on interface requirements, data standards 
used in the insurance industry, and other InsWeb applications. 

2.2.2.2.1 Direct 

There will be no data passed directly to the EGBRE from the Product Data Entry interface. 

2.2.2.2.2 Indirect 

This data will have been collected during one or more previous sessions. It is stored by the Product Data Entry 
Interface (or Batch Rating Data Upload) in persistent storage. 

• The rating engine must allow new coverages and options and new units for existing options to be added without 
modifying the rating engine programming. 
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Therefore, this list of coverages is only suggestive of the coverages necessary to perform a rating. Many of the 
options will have dollar values, some will have "Y" or "N" values, and some will have arbitrary strings for values. 



• Product type 

• Stop-loss 

• Yearly deductible, individual 

• Yearly deductible, family 

• Yearly coinsurance 

• Yearly out of pocket maximum 

• Physician PCP services copay 

• Specialist services copay 

• Chiropractic services copay 

• Inpatient hospital copay 

• Outpatient hospital emergency room copay 

• Outpatient hospital surgery copay 

• Prescription drugs generic copay 

• Prescription drugs brand copay 

• Maternity 

• Mental health 

• Substance abuse 

• Durable medical equipment 

• First dollar accident coverage 

• Transplant coverage 

• Infertility drugs 

• Home health 

• Skilled nursing facility 

• Preventive coverages 

• Hospice coverages 

• Network 

• Minimum group size (may determine eligibility) 

• Maximum group size (may determine eligibility) 

• Geographic area 



2.2.3 Referral Interface 

Depending on consumer request and possibly other factors, the Employee Group Benefits application transmits 
consumer supplied and other requested information to the insurance company, either immediately or as part of a 
later batch process. Summary logging data stored by the EGBRE may be used for this purpose. 



2,2.3.1 Data (output) 

This data will include: 

• Consumer identification 

• Plan design identification 

• Total rating 

• Rating by employee 

• Rating by segment 

• Rating by employee by segment 
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2.2.4 Rating Data Reporting 

Rating Data Reporting will enable insurance product maintainers to confirm that product data has been correctly 
entered and is complete. Data presented will be of two types: 

• Tabular presentation of raw option and factor data driving rate calculations. 

• Formatted reports representing insurance product structure, options, factor calculation formulae, etc. 
2.2.4.1 Data 

There will be no data interface between the EGBRE and the Rating Data Reporting module. 

2.2.5 Batch Rating Table Upload 

Focus will be on determining the complex data mapping necessary to automatically convert data from legacy 
formats to InsWeb formats and a metadata framework for simplifying the process of adding new formats as new 
insurance companies see the light. 

2.2.5.1 Data 

The requirements for data interface between the Batch Rating Table Upload module and the Product Data Entry 
module is identical and described in the product data entry module above. 

2.2.6 Batch Rating Calculation 

The batch rating calculation module calculates the ratings for many combinations of options and factors included in 
batch file. It will be used for internal testing and to convince insurance companies that the rating engine is reliable. 

2.2.6.1 Data 

The requirements for data interface between the batch rating calculation module and the consumer inquiry interface 
module is identical and described in the consumer inquiry interface module above. 
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2.3 Dataflows 

2.3.1 Background Data Setup 

This rarely changed data will be entered by an InsWeb administrator. Data includes product types, insurance 
companies, coverages, options, and networks. This data is not specific to any product or consumer. Data flow is 
trivial, since it can be entered one record at a time. This data is used primarily for verification and for providing full 
names for data display. 

2.3.2 Table Entry 

This rarely changed data comprises the raw numbers used to designate how a consumer's attributes (geographic 
area, age distribution) affect rates. Some tables will be used for multiple products and even muhiple insurance 
companies, but some tables will be specific to products and even policies. 

It is expected that most table data entry will be via batch import from legacy systems. Batch entry will be concerned 
with matching legacy key information with InsWeb key information rather than with complex data flows. 

The online table maintenance data flow will be trivial, consisting of identifying the table and record to be 
maintained, then entering or modifying the table entry. 

2.3.3 Product Setup 

This data describes a product, mcluding all parameters necessary to define the rate calculation formulae. This data 
will be entered by someone expert in insurance product structures who will be carrier's staff or dedicated InsWeb 
staff (or 3''' party contractors). Steps are: 

1 . Enter product header information. 

2. Enter product design header information. 

3. Select option values for each coverage included to create a policy. 

4. Enter header information for each segment of the policy. 

5. Enter initial coefficient for each segment. 

6. Designate which product factors apply to each segment. 

7. Designate which table or calculation method is to be used to determine the product factor value. 

2.3.4 Consumer Data Entry 

Consumer will provide sufficient information that a rate can be calculated. Consumer will: 

1 . Enter consumer identifying information. If the user is not required to supply actual identification a pseudonym 
supplied by the user or supplied by the system will be used. 

2. Enter preliminary information to guide for which factors to prompt (e.g. product type or insurance company of 
interest, geographic area) 

3. Enter factor values. In some cases this may involve moving to a different page to determine a complex value 
(e.g. census information) and returning. 

4. Request and review the rate, 

5. Modify factor values, policy, product, insurance company, or other items, without having to reenter unchanged 
data. 

6. Request and review new rate. 

7. Save values, enter additional data, and request referral to carrier. Data is archived. 
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2.3.5 Referral 

On a regular basis (perhaps real time) information regarding consumers who have retrieved rate information will be 
downloaded to insurance companies. Possible scenarios include: 

• Once a consumer has seen a quote and has committed to a carrier, consumer, policy, and quote information will 
be passed to the carrier. 

• Monthly statistical information including hits and quotes will be passed to the carrier. 

2.3.6 Rating Calculation 

Before performing the rating calculation, an evaluation is performed to determine if the consumer is eligible for the 
policy. This is done by a separate process which compares consumer factors with policy criteria to determine if the 
product is available to the consumer (depending on interface design, it may not be possible for the consumer to 
choose a policy for which he is not eligible). 

The EGBRE receives policy and consumer data, determines the product's details and calculation formulae, and 
retrieves table values. EGBRE returns a rating (dollar amount per month per employee per segment). 

Information retrieved from the data store includes: 

• Plan design segment headers. 

• Plan design factors (blend and expenses). 

• Plan design calculation parameters (which algorithm to use under which circumstances). 

• Consumer factors. 

• Table entries keyed on the above. 
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2.4 Algorithms 

2.4.1 Rating Evaluation Logic 

The EGBRE does not perform or participate in the rating evaluation logic, but this information is included here for 
convenience. 

For the submitted Policy ID and Consumer (quote) ID. 
Determine that all required data has been entered. 

Verify that geographic area is defined in, or convertible to, correct units (county, zip, or other as required 
by policy). 

Determine that the Consumer qualifies for the Policy 

Verify that consumer group size (participating employees) is >= Policy group minimum size 
Verify that consumer group size (participating employees) is <= Policy group maximum size 
Verify that consumer location (employer, not employee) falls within the Policy's availability area. 

2.4.2 Rating Engine Logic 
2.4.2.1 Basic Algorithm 

The following outlines not only the manner in which data is added and multiplied together, but how the rating 
engine identifies all the data necessary for the rating. 

2.4.2.1.1 Inputs 

The following data is provided directly to the Rating Engine. 

• ConsumerlD 

• CarrierlD 

• ProductID 

• PolicyNo 

• Rating Type (One of "Total rating", "rating by segment", "rating by employee", or "rating by employee by 
segment") 

The CarrierlD, ProductID, and PolicyNo are necessary to uniquely identify the Policy to be rated. The ConsumerlD 
is necessary to uniquely identify the Consumer to be rated. 

2.4.2.1.2 Outputs 

The following data is returned by the Rating Engine to the calling program. 
For the first Policy Segment and each Segment which is identified as separable: 

• Rating 

• Each SegmentNo, SegmentRating (if Segment rating was requested) 

• Each EmployeelD, Rating (if Employee rating was requested) 

• Each EmployeelD, SegmentID, EmployeeSegmentRating (if Employee Segment rating was requested) 
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2.4.2.1.3 Total Rating and Rating by Segment 

Set Rating = 0 

For each Segment for the Policy 

Set SegmentRating = Segment.BaseValue 
For each ProductFactor for the Segment 

If any RatingTableKey.FactorType of the RatingTable of the ProductFactor = "E" and the Rating by 
Employee option was specified: 
Set EmpIoyeeRating = 0 

For each employee who is participating in the Product's Group (for whom exists an EmployeeFactor 
named the same as the Product.lnsuranceType equal to "Y") 

Calculate the ProductFactor Value as described in the next section. 

Set EmpIoyeeRating ^ EmpIoyeeRating + Value 
Set ProductFactor Value = EmpIoyeeRating 

Else 

Calculate the ProductFactor Value as described in the next section. 
EndElse 

Set SegmentRating = SegmentRating * ProductFactor.BaseValue 

Set SegmentRating = SegmentRating * ProductFactor Value 
Return SegmentRating if RatingType = "Segment" 
Set Rating = Rating + SegmentRating 
Return Rating 

2.4.2.2 Calculating the ProductFactor Value 

If any RatingTableKey.FactorType for the RatingTable = E(mployee) and the Rating by Employee option was 
specified, then this procedure will be invoked for each employee. If it is not necessary to provide ratings by 
employee, then the looping through each employee will be done within this procedure. In particular, if a policy 
invokes bracketing for a group census factor, then the EGBRE cannot report ratings by employee. 

Perform table lookup. 

For each RatingTableKey of the RatingTable of the ProductFactor (the number of RatingTableKeys is equal to 
RatingTable.Dimension). 

If any RatingTableKey.FactorType ="E" perform Employee loop as described above. 

If RatingTableKey.KeyType = "E"qua]ity then fmd the table column with value equal to one of the following: 
If RatingTableKey. Key Type = "R" ange then fmd the table column with the smallest value which equals or 
exceeds one of the following: 

If RatingTableKey.KeyType = "L"ocation then find the table column with value which contains one of the 
following (not yet well defined): 

If RatingTableKey.KeyType = "T"rend then lookup the single table value without column key. Then calculate 
the number of months by subtracting the Product.TrendDate from the RatingDate. Exponentiate the table 
return value with the number of months. 

If RatingTableKey.FactorType = "E"mployee then use the EmployeeFactor.FactorValue where 
EmployeeFactor.FactorlD = RatingTableKey. TableKey 

If RatingTableKey.FactorType = "C" then use the ConsumerFactor.FactorValue where 
ConsumerFactor.FactorlD = RatingTableKey.TableKey 

If RatingTableKey.FactorType ^ "P" then one of several possible values can be used for 
PolicyOption.Option Value. If there is a ConsumerOption. Option Value for the coverage then set 
PolicyOption.OptionValue = ConsumerOption.OptionValue. If not then use the policy's 
PolicyOption.Option Value. If there is none, set PolicyOption.OptionValue Option.Option Value where 
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DefaultYN = "Y". Then use the PoHcyOption.OptionValue where PohcyOption.OptionID = 
RatingTableKey.TableKey 

If RatingTableKey.FactorType = "R'* then use the value stored from the previous table lookup. 

With all column keys, perform the table lookup. Use the table DimX where X = RatingTable.Dimension 

If Rating.NextRatingTable IS NULL then return DimX.RatingValue 

Else 

Perform Table Lookup, but use the table named in RatingTable.NextRatingTable 

If RatingTable.NextRelationship = "M"ultiply then multiply the returned values from the two tables. 

If RatingTable.NextRelationship = "E"xponentiate then take the first table's value to the second table's 

power. 

If RatingTable.NextRelationship = "K"ey then use the first table's value as a key in the second table's 
lookup. 
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2.5 Data Entities 

2.5.1 Entity Relationship Diagrams 
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fig. 2 Data Entity Relationship Diagram 
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fig. 3 Administrative Setup Entity Relationship Diagram 
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fig. 4 Plan Setup Entity Relationship Diagram 
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fig. 5 Consumer Setup Entity Relationship Diagram 
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fig. 6 Rating Entity Relationship Diagram 
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2.5.2 Data Dictionary 

Please note that the data dictionary includes both requirements and design information. They are included together 
for convenience. 

2.5.2.1 Carrier 

Common Name: Carrier 

Type: Object Class, Relation 

Definition: Providers of the insurance products to whom the consumer is referred. 

Synonyms: Insurance company, provider 

Key Attributes: Carrier ID 
Dependent Attributes: Carrier Name 
Expected Key Values: 

2.5.2.2 Product 

Common Name: Product 

Type: Object Class, Relation 

Definition: Groups of coverages and a formula for evaluating them, bundled as a product of a carrier. 

Synonyms: Plan 

Key Attributes: Product ID 

Dependent Attributes: Product Description 

Expected Key Values: 

2.5.2.3 Product Type 

Common Name: Product Type 
Type: Attribute of Product 

Definition: Groups of insurance products according to regulations, type of network, and administrative 

style. 

Synonyms: 

Key Attributes: Product Type ID 
Dependent Attributes: Product Type Description 
Expected Key Values: HMO with gatekeeper PCP 

HMO without gatekeeper PCP 

POS in network requires gatekeeper 

POS in network does not require gatekeeper 

POS triple option 

PPO 

EPO 

Indemnity with utilization review 
Indemnity without utilization review 

2.5.2.4 Insurance Type 

Common Name: Insurance Type 

Type : Attribute of Product 

Definition: Type of insurance offered. 

Synonyms: 

Key Attributes: 

Dependent Attributes: 

Expected Key Values:Group medical 

Short-term disability 

Long-term disability 

Long-term care 
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Group dental 
Vision 

Group life/accident/disability 



2,5.2.5 Coverage 

Common Name: Coverage 

Type: Object Class, Relation 

Definition: Attributes of a product affecting its value to the consumer. The consumer may select a value 

for each coverage (or they may be pre-selected by the carrier). 
Synonyms: Coverage 
Key Attributes: Coverage ID 
Dependent Attributes: Coverage Description 
Expected Key Values: Yearly deductible, individual 

Yearly deductible, family 

Yearly coinsurance 

Yearly out of pocket maximum 

Physician PCP services copay 

Specialist services copay 

Chiropractic services copay 

Inpatient hospital copay 

Outpatient hospital emergency room copay 

Outpatient hospital surgery copay 

Prescription drugs generic copay 

Prescription drugs brand copay 

Maternity 

Mental health 

Substance abuse 

Durable medical equipment 

First dollar accident coverage 

Transplant coverage 

Infertility drugs 

Home health 

Skilled nursing facility 

Preventive coverages 

Hospice coverages 

Network 

Group size 

Geographic area 



2.5.2.6 Option 

Common Name: 
Type: 
Definition: 

Synonyms: 

Key Attributes: Option ID 
Dependent Attributes: Option Description 

Expected Key Values: Various dollar amounts for deductibles and copayments. Yes or no for some other coverages. 



Option 

Object Class, Relation 

Sets of two or more values of a coverage from which the consumer may make a selection. 
Different options affect the value and cost of a coverage. 
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2.5.2.7 Policy 

Common Name: Policy 

Type: Object Class, Relation 

Definition: Specified set of options selected by the carrier and consumer. 

Synonyms: Policies 
Key Attributes: Policy ID 
Dependent Attributes: Group minimum size 
Group maximum size 

Expected Key Values: 

2.5.2.8 Network 

Common Name: Network 

Type: Attribute of Policy 

Definition: Groups of service providers including hospitals and doctors. 

Synonyms: 

Key Attributes: Network ID 
Dependent Attributes: Network Description 
Expected Key Values: 

2.5.2.9 Policy Option 

Common Name: Policy Option 

Type: Object Class, Relation 

Definition: The specific options, one for each coverage, selected to be a product by a carrier and chosen 

by a consumer to comprise the specific product for which a rating may be made. 

Synonyms: 

Key Attributes: Policy ID, Option ID 
Dependent Attributes: 
Expected Key Values: 

2.5.2.10 Segment 

Common Name: Segment 

Type: Object Class, Relation 

Definition: A collection of coverages to which the same factors are applied. Each segment has a base 

factor which is to be multiplied by specified product and consumer factors to yield a segment 
rate. The sum of all segment rates is the consumer rating. 

Synonyms: 

Key Attributes: Policy ID, Sequence 
Dependent Attributes: Rating Table ID 
Expected Key Values: 

2.5.2.11 Factor 

Common Name: Factor 

Type: Object Class, Relation 

Definition: Attributes of consumers (or policies) which affect the rate which must be paid to purchase a 

fixed insurance product. 

Synonyms: 

Key Attributes: Policy ID, Factor ID 
Dependent Attributes: 

Expected Key Values:Base Factor (30 year old male normalization) 
Expenses 
Blend 
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2.5.2.12 Consumer 

Common Name: Consumer 
Type: 
Definition: 



Synonyms: 
Key Attributes: 
Dependent Attributes: 
Expected Key Values: 



Object Class, Relation 

An expected purchaser of insurance who uses the InsWeb software to obtain comparative 
insurance rates. 
Customer, insured 
Consumer ID 



2.5.2.13 Consumer Factor 

Common Name: Consumer Factor 
Type: Object Class, Relation 

Definition: The values for relevant factors which are true for a particular consumer. 

Synonyms: Factor 

Key Attributes: Consumer ID, Factor ID 

Dependent Attributes: Factor Value 

Expected Key Values: Geographic 

Inflationary trend 

Group size 

Industry 

Takeover / pre-existing carrier 



2.5.2.14 Employee 

Common Name: Employee 



Type: 
Definition: 
Synonyms: 
Key Attributes: 
Dependent Attributes: 
Expected Key Values: 



Object Class, Relation 

One who works for a consumer and participates in one or more insurance products, 
member 

Employee ID (which may be real, but may be an internally used pseudonym). 



2.5.2.15 Employee Factor 

Common Name: Employee Factor 
Type: Object Class, Relation 

Definition: The values for relevant factors which are true for a particular employee. 

Synonyms: Factor 

Key Attributes: Consumer ID, Factor ID 

Dependent Attributes: Factor Value 

Expected Key Values: Age / sex / family 

Healthy lifestyle / smoker (may depend on age / sex) 



2.5.2.16 Product Factor 

Common Name: Product Factor 



Type: 
Definition: 
Synonyms: 
Key Attributes: 
Dependent Attributes: Table ID 
Expected Key Values: 



Object Class, Relation 

The set of product factors which apply to each segment. 



Policy ID, Sequence, Factor ID 
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2.5.2.17 Rating Table 

Common Name: Rating Table 



Type: 
Definition: 
Ids. 

Synonyms: 
Key Attributes: 
Dependent Attributes: 
Expected Key Values: 



Object Class, Relation 

A collection of numeric entries accessed individually by the Table ID and one or more Factor 

Table 
Table ID 



2.5.2.18 Rating Table Entry 

Common Name: Rating Table Entry 



Type: 
Definition: 

Synonyms: 
Key Attributes: 
Dependent Attributes: 
Expected Key Values: 



Object Class, Relation 

A number. Accessed with the name of the table which contains it and one or more customer 
or product factors which are used to define where in the table the number resides. 
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2.6 Performance 

The following assumptions are made. These parameters may change in the course of the design process of the 
balance of the Employee Group Benefits application. 

2.6.1 Rating Speed 

The rating engine should be able to perform a single request for 100 ratings within three seconds on an otherwise 
idle, well configured, single Pentium 2 - 200 megahertz CPU server, while in mid-stream operation (i.e. not having 
just started). It is expected that as usage increases and these numbers are exceeded, it will be cost effective to 
employ more elaborate hardware. 

2.6.2 Transaction Capacity 

The EGBRE must be able to provide ratings for up to twenty separate requests per minute, each with up to 100 
policy ratings to be performed. 

2.6.3 Accuracy 

The rating engine will handle rate adjustment factors from 0.000001 to 999999.999999. Dollar values of up to 
$999,999.00 for single table entries will be allowed and total ratings of up to $99,999,999,00 will be handled. AH 
calculations will be done to the accuracy of the table entries as entered without intermediate rounding or truncating 
to less than nine significant digits, and the final rating will then be rounded (not truncated) to the nearest penny for 
each employee and segment. Calculated ratings will not vary from the carrier's calculated rating by more than one 
cent per employee and segment (barring carrier error). 

2.6.4 Reliability 

Where products are configured within the EGBRE without modification and all rating tables are correctly entered, 
the EGBRE rating must be the same as the correct rating to within one cent every time. Where it is necessary to 
modify the carrier's product to meet InsWeb's requirements the returned rating must be within one percent of the 
manual rating ninety-nine percent of the time. Carrier's will be expected to submit test policies and risk profiles for 
verification testing. 

2.6.5 Maintainability 

The EGBRE must be developed using standard programming languages and architecture adopted by InsWeb, 
including but not limited to Visual Basic 5.0, C++ 4.0, SQL Server 6.5, OLE (DCOM), and Clink/Slink. 

2.6.6 Data Volume 

The system should be able to support the following data volumes without significant performance degradation (25% 
reduction of ideal condition). The numbers are meant to represent typical values for performance calculations and 
are not to be used as design or implementation limits. By design, there will be no limit on the numbers of records 
except where indicated below other than practical considerations such as total disk space available, performance 
degradation, and the user's ability to enter unique names long enough to permit large numbers of values. 

2.6.6.1 Carriers 

20 Carriers 

2.6.6.2 Products 

5 Products per Carrier = 1 00 Products 

2.6.6.3 Coverage 

100 Coverage records 
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2.6.6.4 Policies 

100 Policies per Product - 10,000 Policies (32,767 Policies per Product maximum) 

2.6.6.5 Options 

20 Coverages per Product and 4 Options per Coverage = 8,000 Options (32,767 Options per Coverage maximum) 

2.6.6.6 Segments 

2 Segments per Policy = 20,000 Segments (2, 147,483,647 Segments maximum) 

2.6.6.7 Policy Options 

1 Policy Option per Coverage and 20 Coverages per Policy = 200,000 Policy Options 

2.6.6.8 Factors 

50 Factors 

2.6.6.9 Consumers 

1 0,000 Consumers per year. Consumer data kept online for one year. 

2.6.6.10 Rating Tables 

100 Tables per Carrier = 10,000 Tables 

2.6.6.11 Product Factors 

5 Factors per Segment = 100,000 Segment Factors 

2.6.6.12 Consumer Factors 

20 Factors per Consumer (Employer) = 200,000 Consumer Factors 

2.6.6.13 Employees 

20 Employees per Consumer = 200,000 Employees 

2.6.6.14 Employee Factors 

10 Employee Factors per Employee = 2,000,000 Employee Factors 

2.6.6.15 Groups 

4 Groups per Consumer = 40,000 Groups 

2.6.6.16 Group Employees 

20 Employees per Group (or 4 Groups per Employee)- 800,000 Group Employee records 

2.6.6.17 Rating Table Entries 

100 Entries per Table = 1,000,000 Rating Table Entries 

2.6.7 Total Data Storage 

With less than 5,000,000 records and less than 100 bytes per record for the high population tables, and multiplying 
by two to account for indices and other DBMS overhead, data storage use will be less than 1,000 megabytes. A 
soon to be released version of Microsoft SQL Server will be able to manage up to 3 gigabytes of data in memory, so 
it is likely that this application will be able to scale substantially beyond these initial projections with excellent 
performance. 
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3. Design Specification 
3.1 Object Model 

The Employee Group Benefits Rating Engine will be implemented as a software object which is capable of 
communicating with other InsWeb objects. Objects of concern to the EGBRE fall into two categories: 

• Calling Objects - objects which request data from the EGBRE. 

• Passed Objects - objects passed to the EGBRE which are responsible for data necessary to the rating 
calculation. 

3.1.1 Calling Objects 

The EGBRE interface method for calling objects is: 

Rating = EGBRE.GetRating(RiskProfile, Policy, RatingDateTime, RatingType) 

where the RiskProfile object includes all data for the consumer and the consumer's employees, and the Policy object 
includes high level policy information. The RatingDateTime is the time the rating is to be effective. Tables used by 
the EGBRE will be the ones in effect at that time. The RatingType specifies whether employee and segment ratings 
are to be returned. 

Upon completion of the calculation, the rating information is returned to the Rating variable of the calling object. 

3.1.2 Passed Objects 

The RiskProfile and Policy objects are passed to the EGBRE with each request for a rating. 

The EGBRE will retrieve policy information as required from the Policy object via the methods which it makes 
available. As each policy requires, the EGBRE will request consumer and employee information from the 
RequestProfile object via its methods. The Interfaces section above includes lists of risk profile data which is likely 
to be used, including consumer factors, employee factors, and policy options which will be part of the rating 
calculation. 

The details of the actual calculation are outlined in the algorithms section. The general approach is that the EGBRE 
determines structural details of the policy, then uses the necessary consumer information to look up rating factors in 
the tables specified by the product. The EGBRE uses information from the policy to determine how the calculation 
proceeds with the numbers returned from the table lookups. 
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3.2 Database 
3.2.1 Schema 

The table structure is intended to serve the needs of all components of the Employee Group Benefits application. 
However, the fields and data types specified here are only those necessary to serve the rating engine. As the needs 
of other components become better defined appropriate fields will be modified or added. 

3.2.1.1 Database Preparation 

IF EXISTS (SELECT * FROM sysobjects WHERE id - objectjdCEBRatingHistory Detail')) 

DROP TABLE EBRatingHistoryDetail 
IF EXISTS (SELECT * FROM sysobjects WHERE id - objectJd('EBRatingHistory')) 

DROP TABLE EBRatingHistory 
IF EXISTS (SELECT * FROM sysobjects WHERE id - object_id('EBArea ')) 

DROP TABLE EBArea 
IF EXISTS (SELECT * FROM sysobjects WHERE id - object_idCEBDim5')) 

DROP TABLE EBDim5 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object Jd('EBDim4')) 

DROP TABLE EBDim4 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object jdCEBDim 3')) 

DROP TABLE EBDimS 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object JdCEBDim2')) 

DROP TABLE EBDim2 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJd('EBDim 1 ')) 

DROP TABLE EBDiml 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object idCEBDimO')) 

DROP TABLE EBDimO 
IF EXISTS (SELECT * FROM sysobjects WHERE id - object JdCEBRatingTableKey')) 

DROP TABLE EBRatingTableKey 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJd('EBRatingTable')) 

DROP TABLE EBRatingTable 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object idC EBProductFactor ')) 

DROP TABLE EBProductFactor 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object idCEBEmployeeGroup')) 

DROP TABLE EBEmployeeGroup 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object JdCEBGroup')) 

DROP TABLE EBGroup 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJd('EBEmployeeFactor')) 

DROP TABLE EBEmployeeFactor 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object_id('EBEmployee')) 

DROP TABLE EBEmployee 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectjd('EBConsumerFactor')) 

DROP TABLE EBConsumerFactor 
IF EXISTS (SELECT * FROM sysobjects WHERE id - object Jd('EBConsumerO) 

DROP TABLE EBConsumer 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdCEBFactor')) 

DROP TABLE EBFactor 
IF EXISTS (SELECT * FROM sysobjects WHERE id - objectJdCEBSegmenf)) 

DROP TABLE EBSegment 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdCEBPolicyOption')) 

DROP TABLE EBPolicyOption 
IF EXISTS (SELECT * FROM sysobjects WHERE id - object_id('EBPolicy')) 
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DROP TABLE EBPoIicy 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdCEBOption')) 

DROP TABLE EBOption 
IF EXISTS (SELECT * FROM sysobjects WHERE id = object_idCEBCoverage')) 

DROP TABLE EBCoverage 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdCEBProduct')) 

DROP TABLE EBProduct 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdC EBInsuranceType ')) 

DROP TABLE EBInsuranceType 
IF EXISTS (SELECT * FROM sysobjects WHERE id = objectJdCEB Carrier')) 

DROP TABLE EBCarrier 

GO 
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3.2.1.2 Table Definitions 

3.2.1.2.1 CREATE TABLE EBCarrier 

( CarrierlD VARCHAR(16) NOT NULL, 

CONSTRAINT PKCarrier 

PRIMARY KEY CLUSTERED (CarrierlD) 

) 

3.2.1.2.2 CREATE TABLE EBInsuranceType 

( InsuranceType VARCHAR(16) NOT NULL, 

CONSTRAINT PKlnsuranceType 

PRIMARY KEY CLUSTERED (InsuranceType) 

) 

3.2.1.2.3 CREATE TABLE EBProduct 

( CarrierlD VARCHAR(16) NOT NULL, 

ProductID VARCHAR(16) NOT NULL, 

InsuranceType VARCHAR(1 6) NOT NULL, 

TrendDate DATETIME NULL, 

CONSTRAINT PKProduct 

PRIMARY KEY CLUSTERED (CarrierlD, ProductID), 

CONSTRAINT FKCarrierofProduct 
FOREIGN KEY (CarrierlD) 
REFERENCES EBCarrier(CarrierlD), 

CONSTRAINT FKInsuranceTypeofProduct 
FOREIGN KEY (InsuranceType) 
REFERENCES EBInsuranceType(lnsuranceType) 

) 

3.2.1.2.4 CREATE TABLE EBCoverage 

( CoveragelD VARCHAR(16) NOT NULL, 

CONSTRAINT PKCoverage 

PRIMARY KEY CLUSTERED (CoveragelD) 

) 



06/20/97 



Page 36 



Employee Group Benefits Rating Engine Requirements Summary & Design Specification 



3.2.1.2.5 CREATE TABLE EBOption 



( CarrierlD V ARCH AR( 1 6) 

ProductID V ARCHAR( 1 6) 

CoveragelD VARCHAR( 1 6) 

OptionNo SMALLINT 



Option Value VARCHAR(64) 
Units VARCHAR(16) 
DefaultYN CHAR(l) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NULL, 



NULL, 
NOT NULL 



DEFAULT "N", 



CONSTRAINT PKOption 

PRIMARY KEY CLUSTERED (CarrierlD, ProductID, CoveragelD, OptionNo), 

CONSTRAINT FKProductofOption 

FOREIGN KEY (CarrierlD, ProductID) 
REFERENCES EBProduct(CarrierlD, ProductID), 

CONSTRAINT FKCoverageofOption 
FOREIGN KEY (CoveragelD) 
REFERENCES EBCoverage(CoverageJD), 

Constraint CKDefaultYNofOption 

CHECK (DefaultYN IN ("Y", "N")) 

) 

3.2.1.2.6 CREATE TABLE EBPolicy 

( CarrierlD VARCHAR(16) NOT NULL, 

ProductID V ARCHAR( 1 6) NOT NULL, 

PolicyNo SMALLINT NOT NULL, 

CONSTRAINT PKPolicy 

PRIMARY KEY CLUSTERED (CarrierlD, ProductID, PolicyNo), 

CONSTRAINT FKProductofPolicy 

FOREIGN KEY (CarrierlD, ProductID) 
REFERENCES EBProduct(CarrierID, ProductID) 

) 
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3.2.1.2.7 CREATE TABLE EBPolicyOption 



( 



CarrierlD 

ProductlD 

PolicyNo 

CoveragelD 

OptionNo 

OptionValue 



VARCHAR(16) 

VARCHAR(16) 

SMALLINT 

VARCHAR(16) 

SMALLINT 

VARCHAR(64) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 



CONSTRAINT PKPolicyOption 

PRIMARY KEY CLUSTERED (CarrierlD, ProductlD, PolicyNo, CoveragelD, OptionNo), 



CONSTRAINT FKPolicyofPolicyOption 

FOREIGN KEY (CarrierlD, ProductlD, PolicyNo) 
REFERENCES EBPoIicy (CarrierlD, ProductlD, PolicyNo), 



CONSTRAINT FKOptionofPolicyOption 

FOREIGN KEY (CarrierlD, ProductlD, CoveragelD, OptionNo) 
REFERENCES EBOption(CarrierlD, ProductlD, CoveragelD, OptionNo) 

) 



3.2.1.2.8 CREATE TABLE EBSegment 



( 



CarrierlD 

ProductlD 

PolicyNo 

SegmentNo 

BaseValue 

SeparateYN 



VARCHAR(16) 

VARCHAR(16) 

SMALLINT 

INTEGER 

NUMERIC(}2, 6) 

CHAR(l) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL 
NOT NULL 
NOT NULL 



IDENTITY, 
DEFAULT U 
DEFAULT 'N', 



CONSTRAINT PKSegment 

PRIMARY KEY CLUSTERED (CarrierlD, ProductlD, PolicyNo, SegmentNo), 



CONSTRAINT UNSegmentNo 

UNIQUE NONCLUSTERED (SegmentNo), 

CONSTRAINT FKPolicyofSegment 

FOREIGN KEY (CarrierlD, ProductlD, PolicyNo) 
REFERENCES EBPoIicy (CarrierlD, ProductlD, PolicyNo), 

Constraint CKSeparateYNofSegment 
CHECK (SeparateYN IN ("Y", "N")) 

) 

3.2.1.2.9 CREATE TABLE EBFactor 

( FactorlD VARCHAR(16) NOT NULL, 

Units VARCHAR(16) NULL, 

CONSTRAINT PKFactor 

PRIMARY KEY CLUSTERED (FactorlD) 

) 
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3.2.1.2.10 CREATE TABLE EBConsumer 

( ConsumerlD VARCHAR(16) NOT NULL, 

ConsumerAlias VARCH AR( 1 6) NULL, 

CONSTRAINT PKConsumer 

PRIMARY KEY CLUSTERED (ConsumerlD) 

) 

3.2.1.2.11 CREATE TABLE EBConsumerFactor 

( ConsumerlD VARCHAR(16) NOT NULL, 

FactorlD VARCHAR(16) NOT NULL, 

FactorValue VARCHAR(255) NULL, 



CONSTRAINT PKConsumerFactor 

PRIMARY KEY CLUSTERED (ConsumerlD, FactorlD), 



CONSTRAINT FKFactorofConsumerFactor 
FOREIGN KEY (FactorlD) 
REFERENCES EBFactor(FactorlD), 

CONSTRAINT FKConsumerofConsumerFactor 
FOREIGN KEY (ConsumerlD) 
REFERENCES EBConsumer(ConsumerlD) 

) 

3.2.1.2.12 CREATE TABLE EBEmployee 

( ConsumerlD VARCHAR(16) NOT NULL, 

EmpIoyeelD VARCHAR(16) NOT NULL, 

CONSTRAINT PKEmployee 

PRIMARY KEY CLUSTERED (ConsumerlD, EmpIoyeelD) 

) 

3.2.1.2.13 CREATE TABLE EBEmployeeFactor 

( ConsumerlD VARCHAR(16) NOT NULL, 

EmpIoyeelD V ARCHAR( 1 6) NOT NULL, 

FactorlD VARCHAR(1 6) NOT NULL, 

FactorValue VARCHAR(255) NULL, 



CONSTRAINT PKEmployeeFactor 

PRIMARY KEY CLUSTERED (ConsumerlD, EmpIoyeelD, FactorlD), 



CONSTRAINT FKFactorofEmployeeFactor 
FOREIGN KEY (FactorlD) 
REFERENCES EBFactor(FactorlD), 



CONSTRAINT FKEmployeeofEmployeeFactor 
FOREIGN KEY (ConsumerlD, EmpIoyeelD) 
REFERENCES EBEmployee(ConsumerID, EmpIoyeelD) 

) 
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3.2.1.2.14 CREATE TABLE EBGroup 

( ConsumerlD VARCHAR(16) 



GroupID 



VARCHAR(16) 



NOT NULL, 
NOT NULL, 



CONSTRAINT PKGroup 

PRIMARY KEY CLUSTERED (ConsumerlD, GroupID) 



) 



3.2.1.2.15 CREATE TABLE EBEmployeeGroup 

( ConsumerlD VARCHAR(16) NOT NULL, 



EmployeelD 
GroupID 



VARCHAR(16) 
VARCHAR(16) 



NOT NULL, 
NOT NULL, 



CONSTRAINT PKEmpIoyeeGroup 

PRIMARY KEY CLUSTERED (ConsumerlD, EmployeelD, GroupID), 

CONSTRAINT FKGroupofEmployeeGroup 
FOREIGN KEY (ConsumerlD, GroupID) 
REFERENCES EBGroup(ConsumerID, GroupID), 

CONSTRAINT FKEmployeeofEmpioyeeGroup 
FOREIGN KEY (ConsumerlD, EmployeelD) 
REFERENCES EBEmployee(ConsumerID, EmployeelD) 



) 



3.2.1.2.16 CREATE TABLE EBProductFactor 



( SegmentNo 
FactorlD 
RatingTablelD 
BaseValue 
Algorithm 
MinimumValue 
MaximumValue 



INTEGER 

VARCHAR(16) 

VARCHAR(16) 

NUMER1C(12, 6) 

CHAR(l) 

NUMERIC(12,6) 

NUMERIC(12,6) 



NOT NULL, 
NOT NULL, 
NULL, 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 



DEFAULT 1, 
DEFAULT "N", 
DEFAULT 1, 
DEFAULT I, 



CONSTRAINT PKProductFactor 

PRIMARY KEY CLUSTERED (SegmentNo, FactorlD), 

CONSTRAINT FKFactorofProductFactor 
FOREIGN KEY (FactorlD) 
REFERENCES EBFactor(FactorlD), 

CONSTRAINT FKSegmentofProductFactor 
FOREIGN KEY (SegmentNo) 
REFERENCES EBSegment(SegmentNo), 

Constraint CKAlgorithmofProductFactor 
CHECK (Algorithm IN ("T", "N")) 
"T = Table 
-N = None 
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3-2.1.2.17 CREATE TABLE EBRatingTable 

( RatingTablelD VARCHAR(16) NOT NULL, 

RatingTabieVersion SMALLINT NOT NULL 

ExpirationDate DATETIME NOT NULL, 

Dimension TINYINT NOT NULL 

NextRatingTable VARCHAR( 1 6) NULL, 
NextRelationship CHAR(l) NOT NULL 



DEFAULT 1, 
DEFAULT I, 
DEFAULT "N", 



CONSTRAINT PKRatingTable 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTabieVersion), 



Constraint CKNextRelationofRatingTable 

CHECK (NextRelationship IN ("N", "M", "E", "K")) 
-- N = None 
-- M = Multiply 
— E = Exponentiate 
-- K = Key 



3.2.1.2.18 CREATE TABLE EBRatingTableKey 

( RatingTablelD VARCHAR(]6) NOT NULL, 

TableKey VARCHAR( 1 6) NOT NULL, 

FactorType CHAR( 1 ) NOT NULL DEFAULT "C", 

KeyType CHAR(l) NOT NULL DEFAULT "E", 



CONSTRAINT PKRatingTableKey 

PRIMARY KEY CLUSTERED (RatingTablelD, TableKey), 



Constraint CKFactorTypeofRatingTableKey 

CHECK (FactorType IN ("P", "C", "E", "R")), 
-- P = Product 

— C = Consumer 

— E = Employee 

— R = Rating Table 



Constraint CKKeyTypeofRatingTableKey 

CHECK (KeyType IN ("E", "R", *'L", "T")) 
~ E = Equality 
~ R = Range 
— L = Location 
. — T - Trend 
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3.2.1.2.19 
( RatingTablelD 

RatingTableVersion 

RatingValue 



CREATE TABLE EBDimO 

V ARCHAR( 1 6) NOT NULL, 

SMALLINT NOT NULL, 

NUMERIC(12, 6) NOT NULL 



DEFAULT 1, 



) 



CONSTRAINT PKDimO 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion), 

CONSTRAINT FKRatingTableofDimO 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTable(RatingTableID, RatingTableVersion) 



3.2.1.2.20 CREATE TABLE EBDimI 

( RatingTablelD VARCH AR( 1 6) NOT NULL, 

RatingTableVersion SMALLINT NOT NULL, 

TableKey 1 VARCH AR( 16) NOT NULL, 

RatingValue NUMERJC(12, 6) NOT NULL 



DEFAULT 1, 



CONSTRAINT PKDiml 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion, TableKeyl), 

CONSTRAINT FKRatingTableofDim 1 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTable(RatingTableID, RatingTableVersion), 

CONSTRAINT FKRatingTableKeylofDiml 

FOREIGN KEY (RatingTablelD, TableKeyl) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey) 



3.2.1 .2.21 CREATE TABLE EBDim2 



( RatingTablelD 

RatingTableVersion 
TableKeyl 
TableKey2 
RatingValue 



VARCHAR(16) 

SMALLINT 

VARCHAR(16) 

VARCHAR(16) 

NUMERIC(12,6) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL 



DEFAULT], 



CONSTRAINT PKDim2 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion, TableKeyl, TableKey2), 



CONSTRAINT FKRatingTableofDim2 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTable(RatingTableID, RatingTableVersion), 

CONSTRAINT FKRatingTableKey lofDim2T 
FOREIGN KEY (RatingTablelD, TableKeyl) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey2ofDim2 

FOREIGN KEY (RatingTablelD, TableKey2) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey) 
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3.2.1.2.22 CREATE TABLE EBDim3 



( RatingTablelD 

RatingTableVersion 

TableKeyl 

TableKey2 

TableKey3 

RatingValue 



VARCHAR(]6) 

SMALLINT 

VARCHAR(16) 

VARCHAR(16) 

VARCHAR(16) 

NUMERJC(12, 6) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL 



DEFAULT 1, 



CONSTRAINT PKDim3 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion, TableKeyl, TableKey2, 
TableKeyS), 

CONSTRAINT FKRatingTableofDim3 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTabie(RatingTabIelD, RatingTableVersion), 

CONSTRAINT FKRatingTableKey 1 ofDimS 

FOREIGN KEY (RatingTablelD, TableKeyl) 

REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey2ofDim3 

FOREIGN KEY (RatingTablelD, TableKey2) 

REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey3ofDim3 

FOREIGN KEY (RatingTablelD, Tab!eKey3) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey) 



3.2.1.2.23 CREATE TABLE EBDim4 

( RatingTablelD VARCHAR(16) NOT NULL, 

SMALLINT NOT NULL, 

V ARCH AR( 1 6) NOT NULL, 

VARCHAR( 1 6) NOT NULL, 

VARCHAR( 1 6) NOT NULL, 

VARCH AR( 1 6) NOT NULL, 

NUMERIC( 1 2, 6) NOT NULL 



RatingTablelD 

RatingTableVersion 

TableKeyl 

TableKey2 

TabIeKey3 

TableKey4 

RatingValue 



DEFAULT 1, 



CONSTRAINT PKDim4 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion, TableKeyl, TableKey2, 
TableKeyS, TableKey4), 

CONSTRAINT FKRatingTableofDim4 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTable(RatingTablelD, RatingTableVersion), 

CONSTRAINT FKRatingTableKey lofDim4 

FOREIGN KEY (RatingTablelD, TableKeyl) 

REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey2ofDim4 

FOREIGN KEY (RatingTablelD, TableKey2) 

REFERENCES EBRatingTableKey(RatingTableID, TableKey), 
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CONSTRAINT FKRatingTableKey3ofDim4 

FOREIGN KEY (RatingTablelD, TableKeyS) 
REFERENCES EBRatingTab!eKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTab]eKey4ofDim4 

FOREIGN KEY (RatingTablelD, Tab]eKey4) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey) 

) 



3.2.1.2.24 CREATE 

( RatingTablelD 

RatingTableVersion 

TableKey 1 

TableKey2 

TableKey3 

TableKey4 

TableKeyS 

RatingValue 



TABLE EBDImS 

VARCHAR(16) 

SMALLINT 

VARCHAR(16) 

VARCHAR( 16) 

VARCHAR(16) 

VARCHAR(16) 

VARCHAR(16) 

NUMERIC(12,6) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL 



DEFAULT 1, 



CONSTRAINT PKDimS 

PRIMARY KEY CLUSTERED (RatingTablelD, RatingTableVersion, TableKey 1, TableKey2, 
TableKey3, TableKey4, TableKeyS), 

CONSTRAINT FKRatingTableofDim5 

FOREIGN KEY (RatingTablelD, RatingTableVersion) 
REFERENCES EBRatingTable(RatingTablelD, RatingTableVersion), 



CONSTRAINT FKRatingTableKey 1 ofDimS 

FOREIGN KEY (RatingTablelD, TableKey 1) 
REFERENCES EBRatingTableKey(RatingTabIelD, TableKey), 



CONSTRAINT FKRatingTableKey2ofDim5 

FOREIGN KEY (RatingTablelD, TableKey2) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey3ofDim5 

FOREIGN KEY (RatingTablelD, TableKey3) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatmgTableKey4ofDim5 

FOREIGN KEY (RatingTablelD, TableKey4) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

CONSTRAINT FKRatingTableKey5ofDim5 

FOREIGN KEY (RatingTablelD, TableKeyS) 
REFERENCES EBRatingTableKey(RatingTableID, TableKey), 

) 
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3.2.1.2.25 CREATE TABLE EBArea 



( 



AreaNo 

ParentAreaNo 

ArealD 

AreaType 

AreaName 



VARCHAR(16) 
VARCHAR(16) 
VARCHAR(16) 
VARCHAR(16) 
VARCHAR(16) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 



CONSTRAINT PKArea 

PRIMARY KEY CLUSTERED (AreaNo) 

) 



3.2.1.2.26 CREATE TABLE EBRatingHistory 



( 



ConsumerlD 

CarrierlD 

ProductlD 

PoIicyNo 

RatingDate 

RatingNo 

Rating 

RatingType 



VARCHAR(I6) 

VARCHAR(16) 

VARCHAR(16) 

SMALLINT 

DATETIME 

INTEGER 

NUMERIC(12,6) 

VARCHAR(16) 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL, 



DEFAULT GETDATEO, 
IDENTITY, 
DEFAULT 0, 



CONSTRAINT PKRatingHistory 

PRIMARY KEY CLUSTERED (ConsumerlD, CarrierlD, ProductlD, PoIicyNo, RatingDate), 
CONSTRAINT UNRatingNo 

UNIQUE NONCLUSTERED (RatingNo), 
CONSTRAINT FKConsumerlDofRatingHistory 

FOREIGN KEY (ConsumerlD) 

REFERENCES EBConsumer(ConsumerlD), 



3.2. 1 .2.27 CREATE TABLE EBRatingHistoryDetail 

( RatingNo INTEGER NOT NULL, 

SegmentNo INTEGER NOT NULL, 

SegmentRating NUMERIC(12,6) NOT NULL DEFAULT 0, 

CONSTRAINT PKRatingHistoryDetail 

PRIMARY KEY CLUSTERED (RatingNo, SegmentNo), 

CONSTRAINT FKSegmentofRatingHistoryDetail 
FOREIGN KEY (SegmentNo) 
REFERENCES EBSegment(SegmentNo) 

) 
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4. Appendices 

4.1 Example Rate Calculation 

The mythical Ex InsCo Prism Group Employee Medical Benefits Product 

4.1 .1 Product Eligibility Rules 

Group size minimum = 1 
Group size maximum = 50 

Maternity is mandatory for groups of 10 or more employees. 

4.1 .2 Consumer Risk Profile 

These parameters were chosen to require the rating engine to use a variety of table entries. 

State of Colorado, City of Boulder 
Group Size of 4 employees 

Employee Spouse #Children 



30M 25F 
45M 

35F 38M 
28F 

of rating is May, 1997 



2 



2 
3 
4 



4 



Month 



4.1.3 Policy Option 



These options were chosen to force the most complex calculations for each choice. 



Deductible 
Coverage % 
Stop Loss 
Maternity 

Supplemental Accident & DXL 
Alcohol Rider 
Managed Care Factor 



$750 
80% 
$2500 
Yes 



Yes 



Yes (no impact) 
PHN with Utilization Review 
Sloans Lake 



Out of Network Differential 
PCS Option 

Don't do non-medical coverages in 



30% 

Yes 



this example. 
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4.1.4 Carrier's Algorithm 

1 . From Medical Base Rates, Rate Basis Type = Maternity (optional): for each employee 

1.1. $143.95 

1.2. $ 56.54 

1.3. $143.55 

1.4. $ 40.30 

1.5. Total of $384.34 $384.34 

2. Product Variation Factor 

2.1. Coverage %= 80% 

2.2. Stop Loss = $2500 

2.3. Deductible = $750 

2.4. Factor = 0.6256 $384.34 * 0.6256 = $240.443 1 

3. Supplemental Accident & DXL: for each employee 

3.1. $6.42 

3.2. $1.63 

3.3. $6,42 

3.4. $1.63 

3.5. Total of $16.10 $16.10 + $240.4431 = $256.5431 

4. Rate Area Factor 

4.1. Rate Area = 11 

4.2. Factor = 1.048 

4.3. Exponentiate 1.048 ** (W - 1)- 1.5981 1.5981 * $256.5431 -$409.9815 

5. Managed Care Factor 



0,9184 * $409,9815 = $376,527 

0.93605 * $376,527 = $352.4481 



$34.94 + $352.4481 = $387.3881 



5.1. Grouping of 2 0.9184 

5.2. Out of Net Differential 0.93605 

6. PCS Option: for each employee 

6.1. $12.57 

6.2. $ 6.81 

6.3. $12,57 

6.4. $ 2.99 

6.5. Total of $34.94 

7. Trend Factor 

7.1. Coefficient is 3.0544 

7.2. Months is 7 

7.3. Monthly trend factor is 1.0125 

7.4. 3.0544 * (1,0125 ** 7) = 3.3320 3.3320 * $387.3881 = $1290.7771 

8. Non-medical coverages not considered in this example. 

9. The final rating returned is $1290.78, which is the monthly premium for the four employees and their 
dependents. 



06/20/97 



Page 47 



Employee Group Benefits Rating Engine Requirements Summary & Design Specification 



4.1 .5 InsWeb Rating Array Setup 

For each segment and factor the table name, then the returned factor *s value for the example is given. 
(P) designates a product related factor 



y^j 

Factor 


Segment 1 - Base 


DCgment z - acc oc uaIj 




Starting Base 
Age/Sex/Family (C) 
Product Variation (P) 
Family (C)+(P) 
Area (C) 

Managed Care Factor (PC) 
Out of Net Differential (P) 
Trend (C) 
Segment Result 
Rating = $1290.76 


1.0 

MBR- $384.34 
PVF - 0.6256 

RAF - 1.5981 

MCF (B-NO)- 0.9184 

DF - .93605 

TF- 3.3320 

$1100.64 


1.0 

SADXL- $16.10 

RAF - 1.5981 

MCF (B-NO) -0.9184 

DF - .93605 

TF - 3.3320 

$73.70 


1.0 

PCS - $34,94 

TF- 3.3320 
$116.42 
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4.1.6 EGBRE Calculations 

Rating = 0 

4.1.6.1 Segment One 

SegmentRating = Segment.BaseValue = 1 
Segment.SeparateYN = "Y" 

4.1.6.1.1 Product Factor 1 - Age / Sex / Family 
ProductFactor.AIgorithm = "T"able 
ProductFactor.RatingTablelD = MBR 
ProductFactor.BaseValue = I 
RatingTable.Dimension = 3 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "E"mployee 
RatingTabieKey.TableKey(l) = Age 
RatingTabieKey.KeyType(l) = "R"ange 

RatingTableKey.FactorType(2) = "E"mployee 
RatingTabIeKey.TabIeKey(2) = Family 
RatingTableKey.KeyType(2) = "E"quality 

RatingTableKey.FactorType(3) = "Consumer 
RatingTableKey.TableKey(3) = Maternity 
RatingTabIeKey.KeyType(3) = "E"quality 

Because there is a RatingTableKey.FactorType = "E"mployee, a table lookup will be done for each employee and 

the returned values will be added for all employees. 

For each employee in the product's group 

Dim3.TableKeyl = Min value >= EmployeeFactor.FactorValue for FactorlD = Age {30, 45, 35, 28} 
Because RatingTableKey.KeyType(l) = "R"ange, look in table Dim3 for the least TableKey 1 greater than 
EmployeeFactor.FactorValue for FactorlD = Age 

Dim3.TableKey2 = EmployeeFactor.FactorValue for FactorlD = Family {2A+C, 1 A, 2A+C, 1 A} 

Because RatingTableKey.KeyType(2) = "E"quality, look in table Dim3 for the TableKey2 equal to 
EmployeeFactor.FactorValue for FactorlD = Family 

Dim3.TableKey3 = ConsumerFactor.FactorValue for FactorlD = Maternity {Yes - optional} 
Because RatingTableKey.KeyType(3) = "E"quality, look in table Dim3 for the TableKey3 equal to 
ConsumerFactor.FactorValue for FactorlD = Maternity 

Add the table values as they are collected. {143.95 + 56.54 + 143.55 + 40.30} 

SegmentFactorRating = 384.34 
SegmentRating = 1 * 384.34 = 384.34 



06/20/97 



Page 49 



Employee Group Benefits Rating Engine Requirements Summary & Design Specification 



4.1 .6.1 .2 Product Factor 2 - Plan Variation 

ProductFactor.Algorithm = "T"able 
ProductFactor.RatingTablelD = PVF 
ProductFactor.BaseValue = 1 
RatingTable.Dimension = 3 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = T"lan 
RatingTableKeyTableKey(l) = CoveragePercentage 
RatingTableKey.KeyType(l) = "E"quality 

RatingTableKey.FactorType(2) - "P"!an 
RatingTabIeKey.TableKey(2) = StopLoss 
RatingTableKey.KeyType(2) = "E"quaiity 

RatingTableKey.FactorType(3) = "P"ian 
RatingTableKey.TableKey(3) = Deductible 
RatingTableKey.KeyType(3) - "E"quality 

Because there is a RatingTableKey.FactorType = "P"lan one of several possible values can be used for 
Policy Option .Option Value. If there is a ConsumerOption. Option Value for each coverage then set 
PolicyOption.Option Value = ConsumerOption.OptionValue. If not then use the policy's PolicyOption.OptionValue. 
If there is none, set PolicyOption.OptionValue = Option.OptionValue where DefaultYN = "Y". 

Dim3TableKeyl - PolicyOption.OptionValue for CoveragelD - " CoveragePercentage " {80} 
Dim3.TableKey2 = PolicyOption.OptionValue for CoveragelD - " StopLoss " {2500} 
Dim3.TabIeKey3 = PolicyOption.OptionValue for CoveragelD = " Deductible " {750} 
Because all 3 RatingTableKey.KeyType - "E"quality, look in table Dim3 for the TableKey equal to the respective 
values of EmployeeFactor.FactorValue to obtain the value {0.6256} 

SegmentFactorRating = 0.6256 
SegmentRating - 384.34 * 0.6256 - 240.443104 
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4.1.6.1.3 Product Factor 3 - Area 

ProductFactor.Algorithm = "T" 
ProductFactor.RatingTablelD = RateAreaFactor 
ProductFactor.BaseValue = 1 
RatingTable.Dimension = 2 
RatingTable.ExpirationDate > RatingDate passed 

RatingTab!eKey.FactorType(l) = "P"Ian 
RatingTableKey.TableKey(l) = CoveragePercentage 
RatingTableKey-KeyType(l) = "E"quality 

RatingTableKey.FactorType(2) = 'T"lan 
RatingTableKey.TableKey(2) = Deductible 
RatingTab!eKey.KeyType(2) = "E"quality 

Because there is a RatingTableKey.FactorType = "P"lan one of several possible values can be used for 
PolicyOption. Option Value. If there is a ConsumerOption.OptionValue for each coverage then set 
PolicyOption.OptionValue = ConsumerOption.OptionValue. If not then use the policy's PolicyOption.Option Value. 
If there is none, set PolicyOption.OptionValue = Option.OptionValue where DefaultYN = "Y". 

Dim2TableKeyl = PolicyOption.OptionValue for CoveragelD = " CoveragePercentage {80} 
Dim2TableKey2 = PolicyOption.OptionValue for CoveragelD = " Deductible " ' {750} 

Look in table Dim2 using the above keys (equality) to obtain the value { 1 .048} 

Because RatingTable.NextRatingTable = CountiesinColorado a second table lookup is done 

RatingTable.Dimension =1 

RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType = "Consumer 

RatingTableKey.TableKey = Location 

Diml .TableKey 1 matches ConsumerFactor.FactorValue for FactorlD = Location {Boulder} 
Because RatingTableKey.KeyType - "L"ocation, look in table Diml for the greatest TableKey 1 which is a 
prefix for ConsumerFactor.FactorValue for FactorlD = Location {10} 

* Note that design of the area lookup function depends on more detailed requirements to be developed as part 
of the consumer inquiry interface specification. 

Because RatingTable.NextRelationship = "E"xponentiate calculate Dim2.RatingValue ** DimLRatingValue {1.048 
** 10 = 1.5981} 

SegmentFactorRating = 1.5981327 

SegmentRating- 1.5981327 * 240.443104 = 384.25999 
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4.1.6.1 .4 Product Factor 4 - Managed Care Factor (and Out of Net Differential) 
ProductFactor.Algorithm = "T" 

ProductFactor.RatingTablelD = ManagedCareGroupings 
ProductFactor.BaseValue = 1 
RatingTable.Dimension = 3 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "P"lan 
RatingTableKey.TableKey(l) = Network 
RatingTableKey.KeyType(l) - "E"quality 

RatingTableKey.FactorType(2) = "P'Man 
RatingTabIeKey.TableKey(2) = ProductType 
RatingTableKey.KeyType(2) = "E"qua]ity 

RatingTab}eKey.FactorType(3) = "Consumer 
RatingTableKey.TableKey(3) = Location 
RatingTableKey.KeyType(3) = "E"quality 

Because there is a RatingTableKey.FactorType = "P'Man one of several possible values can be used for 
PolicyOption.OptionValue. If there is a ConsumerOption.OptionValue for each coverage then set 
PoIicyOption.OptionValue = ConsumerOption.OptionValue. If not then use the policy's PolicyOption.OptionValue. 
If there is none, set PolicyOption.OptionValue = Option.OptionValue where DefaultYN = "Y". 

Dim2.TableKeyl - PolicyOption.OptionValue for CoveragelD -Network {Sloans Lake} 

Dim2.TableKey2 = PolicyOption.OptionValue for CoveragelD =ProductType {PHN} 
Dim2.TableKey3 = ConsumerFactor.FactorValue for FactorlD = Location {Boulder} 

Look in table Dim3 using the above keys (equality) to obtain the value {2} 

Because RatingTable.NextRatingTable - ManagedCareFactor a second table lookup is done. 

Because RatingTable.NextRelationship = "K"ey the value just retrieved (2) is used as a key value in the next table 

lookup. 

RatingTable.Dimension = 5 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "R"ating Table 
RatingTabIeKey.TableKey{l) = ManagedCareGroupings 
RatingTableKey.KeyType(l) = "E"quality 

RatingTabIeKey.FactorType(2) = "P"lan 
RatingTableKey.TableKey(2) = UtilizationReview 
RatingTableKey.KeyType(2) - "E"quality 

RatingTableKey.FactorType(3) = "P"lan 
RatingTableKeyTableKey(3) - ProductType 
RatingTabIeKey.KeyType(3) = "E"quality 

RatingTableKey.FactorType(4) - 'T"lan 
RatingTableKey.TableKey(4) = CoveragePercentage 
RatingTableKey.KeyType(4) = "E"quality 
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RatingTableKey.FactorType(5) = "P"]an 
RatingTableKey.TableKey(5) = Deductible 
RatingTableKey.KeyType(5) = "E"qua]ity 

Because there is a RatingTableKey.FactorType = "P"ian one of several possible values can be used for 
PoIicyOption.OptionValue. If there is a ConsumerOption.OptionValue for each coverage then set 
PolicyOption.OptionValue = ConsumerOption.OptionValue. If not then use the policy's 
PoIicyOption.OptionValue. If there is none, set PolicyOption.OptionValue = Option.OptionValue where 
DefaultYN = "Y". 



DimS.TableKeyl = value returned from table ManagedCareGroupings {2} 

Dim5.TableKey2 = PolicyOption.OptionValue for CoveragelD = UtilizationReview {Y} 

Dim5.TableKey3 = PolicyOption.OptionValue for CoveragelD = ProductType {PKN} 

Dim5.TableKey4 = PolicyOption.OptionValue for CoveragelD = CoveragePercentage {80} 

Dim5.TableKey5 = PolicyOption.OptionValue for CoveragelD = Deductible {750} 

Look in table Dim5 using the above keys (equality) to obtain the value {0.9184} 



Because RatingTable.NextRatingTable = DifferentialFactors, yet a third table lookup is done. 

Because RatingTable.NextRelationship = "M"ultiply the value just retrieved (2) is muhiplied by the value to be 

retrieved in the next table lookup. 

RatingTable. Dimension = 2 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey,FactorType(l) = "P"lan 
RatingTableKey.TableKey(l) = ProductType 
RatingTableKey.KeyType(l) = "E"quality 

RatingTableKey.FactorType(2) = "P"Ian 
RatingTableKey.TableKey(2) = OONetDifferential 
RatingTabIeKey.KeyType(2) = "E"quality 

Because there is a RatingTableKey.FactorType = "P"lan one of several possible values can be used for 
PolicyOption.OptionValue. If there is a ConsumerOption.OptionValue for each coverage then set 
PolicyOption.OptionValue = ConsumerOption.OptionValue. If not then use the policy's 
PolicyOption.OptionValue. If there is none, set PolicyOption.OptionValue = Option. OptionValue where 
DefaultYN - "Y". 

Dim2.TableKey 1 = PolicyOption.OptionValue for CoveragelD = ProductType {PHM} 
Dim2.TableKey2 = PolicyOption.OptionValue for CoveragelD = OONetDifferential {30} 
Look in table Dim3 using the above keys (equality) to obtain the value {0,93605} 

Because RatingTable.NextRelationship = "M"ultiply calculate Dim5.RatingValue * Dim2.RatingValue 
{0.9184 * 0.93605 - 0.85966832} 

SegmentFactorRating = 0.85966832 

SegmentRating = 384.25999 * 0.85966832 = 330.33614 
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4.1.6.1.5 Product Factor 5 - Trend 

ProductFactor.Algorithm = "T"able 
ProductFactor.RatingTablelD = Trend 
ProductFactor.BaseValue = 3.0544 
RatingTable.Dimension = 0 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "Consumer 
RatingTableKey.TableKey(l) = RatingDate 
RatingTableKey.KeyType(l) = "T'Vend 

Look in table DimO using the above keys (equality) to obtain the RatingValue { 1 .0125} 

Because the Dimension is 0, no key is actually necessary for the table lookup (but it is required to locate the 
Key Type!). Because the Key Type is "T", the RatingValue is raised to a power equal to the number of months 
between the RatingDate and the Product.TrendDate{7). {1.0125 ** 7} 

SegmentFactorRating- 3.0544 * 1.0908505 - 3.3318937 
SegmentRating -330.33614 * 3.3318937- 1100.6449 

4.1.6.1.6 Segment One Result 

The resulting segment one rating is $1 100.64 
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4.1,6.2 Segment Two 

4.1.6.2.1 Product Factor 1 - Family (Supplemental Accident) 

ProductFactor. Algorithm = "T"able 
ProductFactor.RatingTablelD = SADXL 
ProductPactor.BaseValue = I 
RatingTable.Dimension = 3 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "E"mployee 
RatingTableKeyTableKey(l) = Family 
RatingTableKey.KeyType(l) = "E"quality 

RatingTableKey,FactorType(]) = T"Ian 
RatingTableKey.TableKey(l) = CoveragePercentage 
RatingTableKey.KeyType(l) = "E"quality 

RatingTableKey.FactorType(2) - T"Ian 
RatingTabieKey.TableKey(2) = Deductible 
RatingTab]eKey.KeyType(2) = "E"quality 

Because there is a RatingTableKey.FactorType = 'T"lan one of several possible values can be used for 
PolicyOption. Option Value. If there is a ConsumerOption. Option Value for each coverage then set 
PolicyOption. Option Value = ConsumerOption.OptionValue. If not then use the policy's PolicyOption.OptionValue. 
If there is none, set PolicyOption. Option Value = Option. OptionValue where DefaultYN = "Y". 

Because there is a RatingTableKey.FactorType = "E"mpIoyee, a table lookup will be done for each employee and 

the returned values will be added for all employees. 

For each employee in the product's group 

Dim3.TableKey 1 = EmployeeFactor.FactorValue for FactorlD = Family {2A+C, 1 A, 2A+C, 1 A} 

Because RatingTableKey.KeyType(l) = "E"quality, look in table Dim3 for the TableKeyl equal to 
EmployeeFactor.FactorValue for FactorlD = Family 

Dim3.TableKey2 = PolicyOption. Option Value for CoveragelD = CoveragePercentage {80} 
Dim3.TableKey3 = PolicyOption. OptionValue for CoveragelD = Deductible {750} 

Add the table values as they are collected. {6.42 + 1 .63 + 6.42 + 1 .63} 

SegmentFactorRating = 16.1 
SegmentRating = 1 * 16.1 = 16.1 

4. 1 .6.2.2 Product Factor 2 - Area 

This is the same as Segment 1, Factor 3 

SegmentFactorRating = 1.5981327 
SegmentRating- 1.5981327 * 16.1-25.729936 
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4.1.6.2.3 Product Factor 3 - Managed Care Factor (and Out of Net Differential) 

This is the same as Segment 1, Factor 4 

SegmentFactorRating = 0.85966832 

SegmentRating= 25.729936 * 0.85966832 = 22.1 1921 1 

4.1.6.2.4 Product Factor 4 - Trend 

This is the same as Segment 1, Factor 5 

SegmentFactorRating = 3.3318937 

SegmentRating - 22.1 1921 1 * 3.3318937 = 73.698861 

4.1.6.2.5 Segment Two Result 

The resulting segment two rating is $73.70 
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4.1.6.3 Segment Three 

4.1.6.3.1 Product Factor 1 - Age/Sex/Family 
ProductFactor. Algorithm = "T"able 
ProductFactor.RatingTablelD = PCS 
ProductFactor.BaseValue = 1 
RatingTable.Dimension = 2 
RatingTable.ExpirationDate > RatingDate passed 

RatingTableKey.FactorType(l) = "E"mployee 
RatingTableKey.TableKey(l) = Age 
RatingTableKey.KeyType(l) - "R"ange 

RatingTabIeKey.FactorType(2) = "E'*mployee 
RatingTableKey.TableKey(2) = Family 
RatingTableKey.KeyType(2) = "E"quality 

Because there is a RatingTableKey.FactorType = "E"mpIoyee, a table lookup will be done for each employee and 

the returned values will be added for all employees. 

For each employee in the product's group 

Dim2.TableKey 1 = Min value >= EmployeeFactor.FactorValue for FactorlD = Age {30, 45, 35, 28} 
Because RatingTableKey.KeyType(l) = "R"ange, look in table Dim2 for the least TableKeyl greater than 
EmployeeFactor.FactorValue for FactorlD = Age 

Dim2.TableKey2 = EmployeeFactor.FactorValue for FactorlD = Family {2A+C, 1 A, 2A+C, 1 A} 

Because RatingTableKey.KeyType(2) - "E"quality, look in table Dim2 for the TableKey2 equal to 
EmployeeFactor.FactorValue for FactorlD = Family 

Add the table values as they are collected. {12.57 + 6.81 + 12.57 + 2.99} 

SegmentFactorRating - 34.94 
SegmentRating = 1 * 34.94 - 34.94 

4.1.6.3.2 Product Factor 2 - Trend 

This is the same as Segment 1 , Factor 5 

SegmentFactorRating = 3.331 8937 
SegmentRating = 34.94 * 3.3318937= 116.41636 

4.1.6.3.3 Segment Three Result 

The resuhing segment two rating is $1 16.42 

4.1.6.4 Final Rating 

The resulting rating is $1290.76 
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